Looking back (By TAD)
Introduction
Like most other people of a certain age I booted up a few old 16-bit Amiga and Atari ST emulators to check out some of the fondly remembered games and demos from way back. I thought the chance of viewing them again would lead to some inspiration and/or motivation to get off my arse and do something again. The funny thing was that they didn't live up to the memory. I guess, like most other things in life, everything changes, including us. The once amazing 'how did they do that' was replaced with 'oh no, another 1-bitplane dist-scroller!' With everyone owning hugely powerful machines with more MHz than GB of HD storage, we are spoilt. We moan when we see another 640x480 32bit colour screen throw around 10K polys with music and pixel-effects in another 64KB intro.
Why?
The problem with people, is that we have a great ability to get used to something, even something bad. Once the novelty factor has gone, so too has our attention span.
Back in day, every clock cycle was like gold dust. There were so few people who really knew how to code and be creative, that made them almost god-like. In the history books of the demo-scene are terms like 'raster effect', 'sprite multi-plexing' and 'sync-scrollers'. The amazement came from the fact that doing what seemed like the impossible with a standard configured computer. The number of hours I spent counting clock-cycles, changing the raster colour just to measure a new piece of code to mix 4 channels of noisy 8-bit samples on that crappy AY sound chip in the Atari ST, you would not believe. Just when you finished wiping the sweat and lack of sleep from your eyes and think 'that is THE ultimate routine – nothing can be faster' you think of some other yet more devious plan to cheat the clock-cycle demon out of a few more cycles.
Looking back, I think I've had the most fun with the Atari ST (sure the Amiga kicked its ass in graphics, blitter, sound and copper-list stuff...) but the challenge of doing everything with a 8MHz CPU and some painfully basic hardware was the most rewarding coding I've ever done. Every ST owner was probably aware of TCB (The CareBears), TEX, Delta Force, XXX International, Oxygene (to name a few). These people kicked off my obsession with 68000. Staying up till 5AM trying to figure out faster routines, whilst scribbling down every idea I had to do with 3D graphics.
Back then, there was a feeling of development and exploration. The original hardware designers never thought that 4 channels of digi-music, sprites and full screen scrollers could be done, but that's exactly what most 68K freaks were doing.
I guess younger members in the reading audience will ask what the big deal was. On a machine that could just memory-move 32K (yes only 32K) bytes from word boundary to word boundary in a 50Hz period and nothing else, any type of scrolling was an achievement. On the Atari ST there was NO pixel scrolling, only a 256-byte setting for the screen address. The main screen mode was 320x200 pixels in glorious 16 colours! Each screen line was 160 bytes. Yes, you do the maths: you can only scroll by 1.6 screen lines!! To make matters worse, the screen was bit-plane based with a single pixel being stored in 4 separate words. To draw a 'sprite' you had to shift each word, mask and overlay. On the 68000, the shift instructions took longer as you shift by more bit positions (2n). As you can imagine, shifting by 15 places means 30 Clocks PER WORD, ouch!
The sound chip was just as bad. To output a reasonable 8-bit sample you had to write to 6 registers (1 write to select volume register, 1 write to send the 4-bit data). Not only that, but the volume scale was non-linear, so you had to use a look-up table.
I still remember the day I saw 'The Cuddly Demos' by TCB and 'The Union Demo'. Not only were they original, but technically ground breaking. One of the main appeals of TCB was that they done most of the Amiga hardware demo effects in pure 68000 trickery with a sense of fun!! The silky smooth 'OverScan demo' with a full screen (all borders removed shifted about 60K) with a parallax 16-colour effect, played a looped sample and software sprites. It was totally mind blowing! It showed the clever 'sync-scroller' technique off to the world.
Overscan and Sync-scrolling
Basically 'Overscan' used the trick of switching screen mode at critical points during each and every display line to remove the borders. The basic ST hardware had 3 screen resolutions (640x400 2-colour 70Hz, 640x200 4-colour Or 320x200 at 16-colour with either 50/60Hz refresh rate) and 256-byte screen address registers. One of the first tasks was getting the CPU in sync with the display by reading the raster register and delaying the CPU for a few clock cycles. After this, simply use NOP's and writes to set the screen Mode and 50/60Hz rate. Of course the timing had to be exact, miss a few cycles and suffer a screwed up flickering display.
I saw the fullscreen effect by ILJA in The Union Demo, but that was a static screen with one sprite. The effect was impressive, since the hardware wasn't designed to do this! An overscan screen is roughly 230 bytes per line ( 460 x 300+ lines).
The problem was, since the CPU is tied to the display (a cycle-for-cycle match) you had very little time (or free CPU registers) to do much else.
Along came 'sync-scrolling' and opened up a few more Amiga-like effects that would normally be impossible.
Sync-scrolling was developed from the fact that removing the left and/or right borders made the screen line bigger or smaller, this made the screen lines underneath move left or right. If you combined a number of line overscan routines with different screen widths and adjusted the 256-byte screen boundary then you could get 16-bit scrolling in roughly 8-10 raster lines of CPU time (about 2560 Clock-cyles) about 4% CPU time in 50Hz.
I can remember tweaking code and getting 8-pixel and 4-pixel scrollers working and yes, there were many, many late night coding sessions trying to get it stable.
Shifting the CPU time
For sprites, the only option was to reduce the number of bit-planes and store several pre-shifted versions of the same sprite at different bit positions (usually every 1 or 2 pixels).
Another common trick was 'compiling' sprites into pure 68000 routines instead of using a general routine to read from memory and then overlay. The sprite data was optimised into a single load and multi-write operations since this worked out the fastest way. Look any most big scrollers and you see how blocky the characters are (the same data is written to 8-lines or more).
Intel and caches
I remember experimenting with a 66MHz Intel 486 and being amazed how much difference a small 8KB cache made to the performance. Even with a crappy Video-7 SVGA card I could do pixel-based distorted, multi-layer tricks and zooms like you wouldn't believe. Adding twice the code would often only increase CPU time by 10-25% it was like some instructions were being lost down the back of the sofa.
Things have definitely changed with the arrival of dedicated hardware cards, ultra-fast CPUs, crazy 3D cards and high quality sound cards.
Coding was better back then?
I have to admit, after loading up the emulators and playing some of the old games and realizing how crap most of them really were. The animation was so simplistic, the sound noisy or just plain lousy and the game play highly repetitive. Back then, the limited resources made games and demos simple by nature as there was no other choice. Even the fondly remembered classic games look and sound dreadful when compared to today's offerings. Take any 64KB demo (Please the Cookie Thing, The Product, anything by AND) and you can see how much quality there is, I just don't mean in terms of hardware. The coding and techniques have developed so much, that optimisation rules often have to be changed every few years to keep pace with CPU and 3D card advances. The once true law of 'pre-calculate everything' is starting to disappear. Only in texture/model/world and sample generation does pre-calc exist anymore. The dynamic flexibility of real-time calculations gives us more freedom to change effects and mix them.
Today there is a wealth of development tools and languages to choose from.
The question is: how do we use them to impress?